1. Field
The disclosed embodiments concern a process for transmitting data between at least one cockpit display screen in an aircraft and at least one remote client system. The disclosed embodiments also concern an aircraft cockpit for this process.
The disclosed embodiments are particularly suited for transmitting data according to the ARINC 661 protocol between an aircraft cockpit and a remote client system ensuring that the data are actually recognized by the remote system.
2. Brief Description of Related Developments
The ARINC 661 protocol was developed by the aeronautics industry to set an industrial standard, on one hand, for a graphic interface of display screens for the CDS “cockpit display system” and, on the other hand, a communication protocol between a client system and the cockpit.
This communication protocol makes it possible to send events, such as the selection of a button, from the cockpit to the client system.
According to the ARINC 661 protocol, the cockpit operating system must have a kernel capable of generating the prioritized structure of the graphic interface from a definition file (DF) during the initialization phase, or definition phase, of the CDS. This kernel also makes it possible to broadcast events.
The definition file is a binary file that therefore contains a list of “widgets” that the client system will need to generate its HMI pages that must be displayed in the cockpit. A given definition file is combined with a single client system (UA—“User Application”), but this client system can use several definition files. The widgets are stored in a library managed by the CDS.
The widgets can be interactive, i.e., they can accept actions by the crew and react to them.
These interactive commands are very practical, since they allow the aircraft pilot to work, purely by way of illustration, from the same support, namely his display screen, to execute and follow a task, such as in-flight fuel delivery. They thus help reduce the pilot's workload and his stress.
But spot malfunctions can be observed in these systems, such as spontaneous updating of data by a client system without action by the pilot of the aircraft.
Consequently, it is imperative to enhance the reliability of the interactive cockpit commands to avoid a command at the wrong time or the corruption of a command by the system, which would have negative effects on the aircraft and its passengers.
In order to protect ARINC 661 data exchanges, communication between the CDS 1 and the remote client system 2 relies on a point-to-point communications system such as the TFTP data-transfer protocol (a simplified file transfer protocol) (FIG. 1).
Secure communication then relies on transmission of an acknowledgement 3 of receipt of ARINC 661 data 4 by the client system 2.
It is known how to connect this remote client system 2 to a computer in charge of controlling this remote client system, to give it the fail safe criterion necessary in the aeronautics field.
However, the use of point to point communication between the CDS 1 and the remote client system including the remote client system 2 and its control computer does not make it possible to be sure ARINC 661 data or notifications are received by the control computer.
It follows that the level of reliability offered by a display screen with interactive commands from a cockpit is insufficient for certain remote client systems of the aircraft like the FUEL system dedicated to in-flight refueling.
French patent application No. 07 57064 by this applicant describes a system and a process for transmitting data between at least one display screen using an interactive command and a client system.
This system makes it possible to obtain a high level of reliability by displaying onscreen a request to confirm new data entered by the crew of the aircraft.
This system consequently involves two actions on the part of the pilot of the aircraft, namely entering the new data himself and consequently modifying previously recorded data and confirming this change.
Before this data transmission process, he must make sure that the right values or changes have been recognized by the remote client system.
Although this system gives very satisfactory results in terms of securing data or commands transmitted from the cockpit to a remote client system, it can still be further improved.
Indeed, some functions offered by the CDS of an aircraft to make it easier to fly, such as updating the weight of the aircraft for low-altitude flight, retiming the aircraft position or inserting a TRN sensor (“Terrain Reference Navigation”) to calculate the hybrid position of an aircraft flying at low altitude, use interactive commands that affect the safety of the aircraft, so these functions require total independence between the data or command acquisition paths by the remote client system and the data or command confirmation paths by the crew.
Now, the system described above does not make it possible to achieve the total independence required. The controls of the display system composed of the keyboard, mouse, display screen and the connection permitting data transmission are common points, since they not only allow the parameters to be updated, but they also allow the updates to be confirmed.
The consequences of a potential failure of these common points are, of course, then critical, not only for the aircraft, but also for the crew and the passengers.